メンバーズのメールシステムを1年掛けて Amazon SES にリプレイスしてみた

本記事は、2019年 11月初旬に発足し 2020年 12月中旬頃に完了したメンバーズサービスで利用しているメールシステムのリプレイスプロジェクト（実話）を元にしたお話です。1年越しのプロジェクトを振り返りながら当時抱えていた課題や、どのようにして解決したかなどを共有してみたいと思います。なお、2020年6月末時点で AWS アカウント数は 8,800 を超えており 2019/6/27 のプレスリリース（キャンペーン記事）内で AWS アカウント数 4000以上と記述があることから、急激なサービススケールに対応するための奮闘記とも言えるでしょう（各プレスリリース記事については、本記事末尾の参考情報をご参照ください）

はじめに

弊社が社内メールシステムとして Google Workspace（旧称 G Suite）を活用しているということもあり Amazon SES にリプレイスする前は、Google グループ（※）を活用したメールシステムを運用しておりました。

（※）メーリングリストのようなグループアドレスを発行し、グループ参加者にメールを配信する仕組み

イメージ図

Google グループという機能自体は、無料で利用することができ非常に便利かつ優れた仕組みです。ただし、メール受信数等の制限事項も存在しており本記事のような AWS アカウントを発行する際に払い出されるルートユーザーの受信用メールアドレス（以降、ルートメアド）として利用した場合、管理している AWS アカウント数によっては問題が発生する可能性があるため、注意が必要です。

リプレイス前の課題

結論から申し上げると、「Google グループの構成」および「AWS から配信されるメール受信数の増加」の課題が組み合わさり Google グループでのメール受信数上限に到達していました。 受信数上限に到達した際は、G Suite 管理者である情シスメンバーの協力を得つつ個別の対応を実施し１年間耐え忍ぶという状況が続きました。

Google グループのポリシーと制限

1 人の外部送信者が Google Workspace アカウント内のすべてのグループに送信できるメール数の上限　1 時間あたり 1,800 通

なお、この 1,800通という上限値はハードリミット（仕組み上緩和不可能な制限値）であるようです。

本事象のポイントは、下記の２つです。

• Amazon Web Services から配信されるメールアドレスのうち no-reply-aws@amazon.com からの受信数がアカウント数増加に比例して増加（1 人の外部送信者に該当）
• 1 時間あたり 1,800 通 は「すべてのグループ」に適用されるため、Google グループ間で転送したり、グループのネスト構成（グループのメンバーとしてグループに追加する）を行うと、１通のメール受信に対して上限数（1 時間あたり 1,800 通）が転送回数分消費される

弊社の場合、Amazon Web Services から配信されるメールを受け取った Google グループが、当初内部的に３つのグループに転送する構成になっていました。そのため、1 時間あたり 1,800 通という上限数が Google グループの構成（１つのメールを４つのグループで受信する構成）を理由に実質上限値が 1 時間あたり 450 通 まで低下していました。

暫定的な対処として Google グループの整理を行い、内部的に３つのグループに転送する構成を１つのグループにまとめ纏めた結果、1 時間あたり 900 通 に実質上限値を緩和することができました。

なお、Google グループでの受信上限に到達した際にフォロー対応が可能な関係者（メンバー）が手薄な年末年始などの長期休暇中は暫定的に Google グループへの転送自体を一時的に廃止し弊社オペレーションチーム（メンバーズのサポートチーム）のみが参照できる Google アカウントにのみ転送することで、1 時間あたり 1,800 通 の上限値を確保していました。

根本問題を解決するための施策

弊社のメンバーズビジネス関係者が、AWS から配信されるメールを閲覧可能な状態にしておきたいという要件と、社内運用フローの兼ね合いで各メンバーが参加している Google グループを卒業することができず、AWS アカウント発行時に登録するルートメアドを Google グループから変更する必要に迫られました。コスト度外視で問題無いのであれば、ルートメアドを Google アカウント（Gmail）に変更することで Google グループの受信上限はクリアできるものの、１ Google アカウント毎に月額 680円程度のコストが発生し、ランニングコストが無視できない金額になってしまうため、他の方法を模索する必要がありました。

• Google Workspace - 料金

そこで、メールシステムのリプレイスに伴って何か別の課題を解決することができないか等を考慮し、全体を俯瞰して検討するために弊社メンバーズのサポートチーム（オペレーションチーム）が抱えている（2019年12月当時の）課題とその要望を、ピックアップしてみました。

• AWS から配信されるメールのうち、メンバーズ顧客が利用している AWS リソースに関するメンテナンス等の通知を人手で選り分け、顧客へ案内している（より迅速に顧客へ案内したい）
• AWS から配信されるメールのうち、メンバーズ顧客が利用している AWS アカウントのインシデント通知等を人手を介して、顧客へ案内している（より迅速に顧客へ案内したい）

いずれの課題も共通して「より迅速に顧客へ案内」したいという要望を背景としており、「自動化できていない」という問題を抱えていました。この課題を解決しつつ、スケーラビリティも確保するという要件を元に選定した結果、「Amazon SES」を選びました。

Amazon SES を利用した PoC およびプロトタイプ開発

ここで、Google グループのメール受信に関する制限を改めて確認してみます。

Google グループのポリシーと制限

1 人の外部送信者が Google Workspace アカウント内のすべてのグループに送信できるメール数の上限　1 時間あたり 1,800 通

AWS から配信されるメールアドレスのうち no-reply-aws@amazon.com （1 人の外部送信者に該当）からのメール受信数がアカウント数増加に比例して増加（下図の①）

そこで、Amazon SES Eメール受信用の受信ルールセットを作成し、AWS から配信されたメールを一旦 S3 バケットに保存します。上図の②でバケットへメールが保存（S3 オブジェクトが作成）された際のイベントにより Lambda を呼び出し Amazon SES で受信したメールのヘッダーを、下記の表に記載されている各アドレスへ差し替えて転送（上図の③）することによって Google グループ視点で考えると 1 人の外部送信者 からの配信ではなくなり、根本的な問題を解決することができそうだなと思いつきました。

メールヘッダー	AWS から配信されたオリジナルメール	Lambda で転送するメール
From	no-reply-aws@amazon.com	AWS アカウントのルートメアド
To	AWS アカウントのルートメアド	Google グループのアドレス

実際に転送用 Lambda を開発し、負荷テスト用 Google グループに対して１時間あたり 3600通程度のテストメール配信処理を流したところ特に問題無く受信できることが確認できました。（PoC 開発〜負荷試験までの流れは、実質３営業日程度のスピード感で 2020年2月中旬頃のお話です）

その後、プロトタイプ開発およびテスト運用を並行しておこなうために、筆者を含むいくつかの社内メンバーが利用している AWS アカウントに適用を行い 2020年7月まで動作確認を行った結果、特に問題は見受けられなかったため 2020年8月に本番リリースを行いました。

立ちはだかる壁〜リプレイスまで

メールシステム自体は Amazon SES 版の本番リリースを終えましたが、完全にリプレイスするには既存の AWS アカウントに設定されている Google グループ版のルートメアドから Amazon SES 版のルートメアドへ順次差し替えていく対応が必要でした。

この「AWS アカウントに設定されているルートユーザーに設定されたメールアドレスを差し替えていく」という作業が非常に骨の折れる作業だったのです。理由はシンプルで、「ルートユーザーに設定されたメールアドレスを差し替える作業」は API が用意されておらず Web インターフェイス（ブラウザ）での変更作業しか対応していなかったことが理由です。人間が１つ１つ地道に変更していくには時間を掛けて単調な作業を繰り返すしかなく、対応が長期に及んだ場合、どこかで必ず作業ミスが発生する可能性を否定できない状況でした。そのため、出来得る限り作業を効率化するための Selenium を利用した半自動化スクリプト（パスワードや認証コードの入力以外は、ほぼ自動化されているルートユーザーの設定メールアドレス変更スクリプト）をプロジェクトメンバーである 千葉 が開発＆用意してくれました！Selenium については、下記の公式ドキュメントをご参照ください。

この Selenium を利用したツール（スクリプト）のお陰で、無事に 2020年12月22日にリプレイス対応を完了させることができました。既にリプレイスが完了してから半年程度が経過しておりますが、システムとしては今も安定稼働しています。この半年間の運用実績（メール受信数）を振り返ってみたいと思います。

プロジェクト発足前の Google グループで運用していた際の実質メール受信上限値 1 時間あたり 450 通 は、多いときにはほぼ毎週発生しているようです。また、１時間の合計メール受信数としては 1,469 通を記録しており、今後もサービスの成長（AWS アカウント数の増加）に伴って、メールの受信数は増えていくものと考えられますが、Amazon SES や AWS Lambda のスケーラビリティによって今後もメンバーズのメールシステムを支えてくれると思います。

さいごに

リプレイス前から移行期間中を含め Google グループの受信数上限に到達した際は、社内の情シスメンバーのみならず、弊社の AWS Japan テクニカルアカウントマネージャーへ情報収集のため協力を要請するなど、プロジェクトメンバーを含め様々な方々の協力が無くては成し遂げられなかった印象が大きいプロジェクトでした。この場を借りて、プロジェクト関係者ならびに、弊社 AWSJ TAM チームの皆様方へお礼申し上げます。本当にありがとうございました！

参考情報